Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm looking for some guidance on how to architect an app with regards to modularity, separation of concerns and re-usability.

I'm working on an application (ASP.Net, C#) that has distinctly generic chunks of functionality, that I'd love to be able to lift out, all layers, into re-usable components. This means the module handles the database schema, data access, API, everything so that the next time I want to use it I can just register the module and hook into it.

Developing modules of re-usable functionality is a no-brainer, but what is really confusing me is what to do when it comes to handling a core re-usable database schema that serves the module's functionality.

In an ideal world, I would register a module and it would ensure that the associated database schema exists in the DB, by creating the schema if it didn't already. I would code my dependent functionality on the assumption that the tables exist calling the module's functionality through the DLL, agnostic of the database layer. Kind of like Enterprise Library's Caching/Logging Application Block, which can create a DB schema in the target DB to use as a data store.

My Questions is: What do you think is the best way to achieve this, firstly, in terms design architecture, and secondly solution structure. What patterns/frameworks do you know that exist & support this kind of thing?

My thoughts so far:

I mostly use Entity Framework and SQL Server DB Projects. I thought about a 'black box' approach to modules of functionality. I could use use a code-first approach in EF4, and use the ObjectContext to create a database when the module is initialized. However this means that all of the entities that my module encapsulates would be disconnected from the rest of the application because they belonged to an abstracted ObjectContext. Further - Creating appropriate indexes and references between domain entities and the module's entities would be impossible to do practically.

I've thought of adopting Enterprise Library and creating my own Application Blocks. I'm not sure how this would play nice with Entity Framework (if at all) though. I like the idea of building on proven patterns & practices to encapsulate established, reusable functionality.

I thought of abandoning Entity Framework for the Module, and just creating a separate DB schema for the module with its own set of stored procedures & ADO.Net. Then deploying the script at run-time if interrogation shows that it doesn't exist. But once again, for developing functionality outside of the module, I would want to use Entity Framework and I would have to use the module separately, disconnected from the domain ObjectContext.

Has anyone had experience developing these sorts of full-stack modules? What advice can you offer? Am I biting off more than I can chew?

share|improve this question

migrated from stackoverflow.com Jun 19 '12 at 13:16

This question came from our site for professional and enthusiast programmers.

add comment

2 Answers

up vote 2 down vote accepted

I have tried a few times. My advice is "don't" -- trying to be everything to everyone means you are nothing to nobody. The best possible result is you end up recreating sharepoint after half a decade of hard work.

share|improve this answer
    
Over engineered database driven applications rarely end well. You end up re-implementing functionality that exist as open source projects. The part about a proven business layer (unit testing) and separating your repository from your business logic is great, but the rest sounds like over engineering –  brian Jun 19 '12 at 14:48
    
I am conscious of over-engineering these blocks too. Most of the scenarios I am considering cover fairly vanilla patterns that I find myself using over and over again, such as: a document/file store, a store of scraped exchange rates, a pattern for tagging objects etc. Another thought that occurred to me that in most scenarios, these bits of functionality could be exposed as services in Service-Oriented Architecture. Maybe this is the a good fine line? –  Martaver Jun 20 '12 at 8:12
    
The trick is you think they are fairly vanilla and repeatable. Until you get really, really into the details and you realize that they aren't exactly the same module and you end up hacking lots of stuff to get things to go. Or you end up with a hugely overconfigurable mess like SharePoint. –  Wyatt Barnett Jun 20 '12 at 13:53
    
So what's your opinion of the way Enterprise Library has provided compartmentalised Application Blocks and extension points for generalisable behaviour? –  Martaver Jun 21 '12 at 4:31
    
I prefer smaller, stronger sharper tools -- IE, Log4Net over the Logging Application Block. –  Wyatt Barnett Jun 21 '12 at 12:08
add comment

With regards to your statement

"In an ideal world, I would register a module and it would ensure that the associated database schema exists in the DB."

If I get the meaning correctly, then I don't think that this requirement is a common practice in most business application. A piece of code has to make assumptions otherwise the options are too many. For example, I don't think that it is practical to check if the "Customer" table exists in the database and it has the correct key, and if the "Invoice" table exists and if there is a relationship exits between them then do action1...and so on. What most of the systems do is fix the schema and re-use the dlls (and/or stored procedures).

share|improve this answer
    
I follow you... I suppose what I'm looking for is a more formal/convenient pattern to 'package' the related schema, procs & dlls that could be lifted from one project to the next. –  Martaver Jun 21 '12 at 4:34
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.