I am developing an e-commerce application using spring and struts. I am quite confused about the following.
What is meant by conceptual view of the system? When I searched in the internet, I could see the diagrams with classes. But my understanding is that conceptual view is something which is derived soon after requirement gathering.
What is architectural view of the system? Can I explain MVC architecture here? or should I go with something else, rather more specific to my application.
Could you please help me figure this out.
Thanks in advance!
The conceptual view (a.k.a. the conceptual schema) is a diagram of concepts that are related, from which a database model can be derived. For example, you might have some students, courses and modules in a conceptual view for a student management application. The model may contain properties about each concept, but only properties that relate to the properties of the real-life concept. You could later convert this into a normalized database format, containing tables that handle any many-to-many relationships, additional fields, etc.
An archictecural view separates parts of a system out into architecture categories. The categories may be related to a layered model (e.g. presentation, logic, data) or any other model. As you mentioned, MVC is a good example here. Such models are useful to understand how a project's resources and components might be partitioned.
Related
I need to create composite key with fluent API dynamically according to database schema.
I google for the solution but can't find any.
Any suggestion how to do that?
Evolving database = evolving classes = evolving mapping. There is no automation for this because your classes don't have to be 1:1 image of your database and it is up to mapping to describe how they relate.
Even doing 1:1 automation is project itself. It is quite complex task and it will take you much longer to built that then simply evolving your mapping manually. Also there is no reason to do that because it already exists in EF Power Tools.
If you still want to do that go to SQL Books online and learn how SQL persists information about tables, columns, relations, constraints, etc. Then learn how to either use T4 templates or CodeDom to generate classes. Use these two set of information to get description of database and create mapping accordingly (it will be much harder if you would like to do that mapping to existing classes btw.).
First a background. Our application is built on ASP.NET MVC3, .NET 4.0, and uses Linq-to-Sql (PLINQO) as its primary means of data access. Our web application is a multi-tenant/multi-client system where each client gets their own Sql Server database. Each Sql Server database up to now has had exactly the same schema.
Often times, clients will ask us to track custom fields in their Db that other clients don't track. The way we've handled this is by reserving a number of customfields in the db in our main tables. For example, our Widget table may have a CustomText1, CustomText2.. CustomText10, and a CustomDate1, CustomDate2..CustomDate10 fields. Again, all our schemas across clients are the same, so Linq-to-Sql handles these fields just as easily as any other field.
Now we are running into an issue where a client wants several hundred CustomBool fields, but doesn't need the others. So, basically, we are researching for ways to still use the Linq-to-Sql, but have it work against potentially different schemas depending on the database it is connected to (although they are different in a very specific way.)
Too much code has already been built on Linq-to-Sql and accessing the Widget classes generated by it that I'd like to not just fall back to straight SQL.
I've seen answers here and on the web on ways for Linq to Sql to access different tables that have the same schema, but I have not found a good answer to the same table name across different dbs with different columns.
Is this possible?
If the main objective is to store a few extra fields for existing domain objects then why not create a generic table that can store key value pairs. This is extremely flexible since there is no need to change your schema if a customer requires a new property.
We do this frequently and normally have some helpers to correctly cast the properties e.g.
Service.GetProperty<bool>("SomeCustomProperty")
If you are looking for a more "pluggable" domain model that can be completely different for each tenant, I think you will struggle if you are following a database driven approach and using the L2S designer to generate your code.
To achieve this you really need to be generating your database based on your code (domain driven design) which will give you much more flexibility i.e. you can load a tenant specific configuration (set of classes, business rules etc.) at runtime and use this to generate/validate your schema.
Update
It would be good if you could elaborate on exactly what design approach you have taken i.e. are you using the Linq designer and generating your model from the database?
It's clear that a generic key value pair store is not going to meet your querying requirements.
It's hard to provide a solution without suggesting a different technology. Relational SQL databases aren't really suited for dynamic domain models. You may be better off with a document database such as MongoDb or RavenDb where you are not tied to a specific schema. You could even make use of these just for your custom properties.
If that's not ideal then another solution would be to use something like Dapper to construct your queries. Assuming you are developing against interfaces you can have a implementation of your data service per tenant that makes use of their custom fields.
Ayende did a whole series of posts on Multitenancy and covers tenant specific domain models. It starts here and may be of some use to you.
I'm recently migrating to Linq2Sql and all my future projects will be using Linq2Sql. Having said that, I researched a lot on how to properly plug-in Linq2Sql in application design.
what to put at what layer ?
How do you design your repositories and business layer services ?
Should I use DTOs over Linq2Sql entities on interaction layer ?
what things should I be careful about ?
what problems did you face ?
I did not find any rock-solid material that really talked about one single thing and everyone have their own opinions. I'm looking forward to your ideas on how to integrate/use Linq2Sql in projects. My priority is maintenance[it should be maintenable and when multiple people work on same project] and scalabilty [it should have scope of evolution].
Thanks.
I have been using linq to entities for the last two and half years on production applications and I can say it has been a really nice experience... but that doesn’t means you should do everything with Linq.
I am going to try to give you some answers to your questions,
I think you should ask first what kind of application you want to create; once the scenario is clear you will have an odd idea of number of transactions or queries you are going to perform against the database (or repository).
Linq could be extremely useful to abstract data access, context and entities handling, but everything comes with at a cost. Objects will be created with a cost and you really need to think about this.
If your application has a ‘nice-not-too-heavy’ data access Linq will be the perfect tool to save time for your application.
If your application is entirely based on data extraction or processing, Linq will be great as well.
If your application is handling huge blocks of data (check your application) you will need to do something else to avoid creating a bunch of objects that might be useless.
What does that means? You need to know what a smart data access means... and that is leave SQL to work for you (in the case of SQL); if you are going to do lots of joints, cross information and stuff, create stored procedures that creates the data result for you and then get it using Linq or SqlCommand or SqlDataAdapters, etc...
What to put at what layer?
Since Linq gives you the data access abstraction you can pretty much place your code where the business logic demands it. There are tons of good practices of how to structure your code; Linq (as any other entity framework or data access libraries) will fit in the right spot.
Avoid whenever is possible direct linq expression in your controls (asp.net has lots of controls with linq data sources), instead wrapped your ‘query’ with a service class that can be instantiated by your code or controls as an object data source.
What have I found?
Pure Linq is not always possible on big applications or projects (so you will end up with many things in linq and some in previous more simple solutions to access your repositories) but will help you to save time.
Implementing stored procedures is a MUST if you want to deliver great quality applications.
Hope this comment helps.
Cheers.
I am currently reading Pro Asp.Net MVC, and they are building all of their linq2sql entity classes by hand, and mapping them with the linq mapping attributes. However, everyone else I see (from google searches) talking about linq 2 sql seem to be using the visual designer for building all of their entities. Which is the preferred way to build l2s entities, and what are the advantages/disadvantages of each?
The only difference I have noticed so far, is I can't seem to do inheritance mapping when using the visual designer, although MSDN says I should be able to so I might just be missing it in VS 2010's interface. However, I'm not so sure I should use inheritance anyway as that could technically add additional joins when I don't need the sub table data.
As a PS, l2s will not be doing any modification of my schema, I will be generating schema changes manually and then replicating them in linq2sql.
Thanks,
We used the designer all the time. It indeed introduces an added step, every time you make a change to the schema you need to import the table into the designer again, but I think that effrot pales in comparison to the amount of code you need to write if you bypass the desginer.
Also note that the designer creates partial classes, you can create an additional file for the partial class that includes additional implementation details. That way, when the table gets refereshed in the designer, it leaves you additional code alone. We do this to add a lot of helper functions to the classes, and also to provide strictly typed enumerated properties that overlay the primitive integer FK fields.
It's true that inheritance would be very difficult to accomplish well, but I think if you need that sort of data layer, L2S may not be the best solution. I prefer to keep my data layer clean and simple, just using L2S to get the data in and out, and then pu more complicated logic in the business layer. If we really needed to do things like object inheritance in our data layer, I would probably explore a more advanced and complicated technology like EF
We've built our entire application framework backend using L2S. I developed most of the this. I started to use the DBML designer but I quickly realized this was a royal pain. Every schema change required a change to the table(s) in the designers. Plus, the entities created by the designer all get stuffed in a single class file, and didn't have all the functionality I wanted, like support for M2M relationships, and more. So, it didn't take long before I realized I wanted a better way.
I ended up writing my own code generator that generates the L2S entities the way I want them, and it also generates a "lightweight" set of entities that are used in the application layer. These don't have any L2S plumbing. The code generator creates all these entities, and other code, directly from a target database. No more DBML!
This has worked very well for us and our entities are exactly the way we want them, and generated automatically each time our database schema changes.
I've looked at several similar questions but I didn't see any that directly applied to me, so forgive me if this is a duplicate.
For separation of concerns I'm trying to somehow map my business objects with logic to the LINQ to SQL data objects in the .dbml file (fairly new to this btw). What its looking like though is that my business objects are going to need to know about the corresponding LINQ2SQL objects. I read this article about trying to use POCOs with by using an xml mapping file, and it seems like that's similar to what I want, except that I don't have a one-to-one mapping from tables to classes because of a many-to-many relationship that I needed to create an extra table for.
I can encapsulate the data access in my business logic pretty well such that code that uses my business objects don't need to know anything about the database which is good, but it the business layer is still tightly coupled with the data access layer such that I couldn't swap out the DAL without either changing my business layer objects or creating new ones (that implement the same interfaces) for different data providers.
How can I decouple these layers?
Not sure if you are tied to LINQ to SQL somehow, but what you are trying to accomplish is pretty much the default in NHibernate. I recommend taking a look at NHibernate to see if it would be easier to switch than to fight LINQ to SQL.
I've found that fighting a tool is almost always a bad idea.